Fully replace libc6-compat and musl-utils
#179
Conversation
| triggers="$pkgname-bin.trigger=/lib:/usr/lib:/usr/glibc-compat/lib" | ||
|
|
||
| package() { | ||
| mkdir -p "$pkgdir/lib" "$pkgdir/usr/glibc-compat/lib/locale" "$pkgdir"/usr/glibc-compat/lib64 "$pkgdir"/etc | ||
| provides="libc6-compat" |
There was a problem hiding this comment.
This declaration isn't accurate but the line below it is.
| provides="libc6-compat" |
There was a problem hiding this comment.
I'm not sure I understand why you think this is incorrect.
In the PR description I wrote:
the intent of
libc6-compatcan be written as "I'd like to be able to run binaries that are linked against glibc", so also sayprovides="libc6-compat".
Or, put another way: What could be more libc6-compatible than actually installing libc6?
There was a problem hiding this comment.
What could be more libc6-compatible than actually installing libc6?
provides is not meant to declare a capability, but should refer to packages provided, see also https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#provides. Further one could argue, the packages from this repository do not provide compatibility, they do provide glibc.
libc6-compat is a package, https://pkgs.alpinelinux.org/packages?name=libc6-compat&branch=v3.16&repo=&arch=&maintainer=.
There was a problem hiding this comment.
@jalberti I think I see why setting provide=libc6-compat is not what we would want; after the suggested reading by @sgerrand :
provides
List of package names (and optionally version info) this package provides.
If package with a version is provided (provides='foo=1.2') apk will consider it as an alternate name and it will automatically consider the package for installation by the alternate name, and conflict with other packages having the same name, or provides.If version is not provided (provides='foo'), apk will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously. However, none of them will be installed by default when requested by the virtual name - instead, error message is given and user is asked to choose which package providing the virtual name should be installed.
This definition shows that provides it meant as an alternate name for installation. Since this is glibc and not just a compatibility, it would make more since to set provide='glibc=2.35'
I'm not familiar with ABUILD, but there must be another way to show conflict between libc6-compat and other packages.
There was a problem hiding this comment.
@jalberti My this would work!?
depends="$pkgname bash !libc6-compat libgcc"
Notice the "!" added before libc6-compat. This makes the most since, and explains why that is in the depends list in the first place.
Excerpt from https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#depends
depends
Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-
detected and should not be specified here. To specify a conflicting package, add the package name prefixed with a '!'.
| pkgdesc="executable programs that come with glibc, installed to /usr/glibc-compat/" | ||
| depends="$pkgname libgcc" | ||
| depends="$depends bash" # shebang for ldd, sotrus, tzselect, xtrace | ||
| depends="$depends perl" # shebang for mtrace | ||
| mkdir -p "$subpkgdir"/usr/glibc-compat |
There was a problem hiding this comment.
so then add
depends="$depends !libc6-compat" # conflicts with this package
|
@LukeShu I believe that this PR is still VERY relevant and should be merged. But with the change I suggested:
Would you be willing to rebase this PR with the latest and push an update? |
Updated the APK build to list libc6-compat as a conflicting package. resolves sgerrand#179.
|
I tried to build and install this PR, however, I ran into the following issue: @LukeShu any thoughts on this? |
When upgrading 2.34→2.35, #171 also made the change that it drops the
/lib64/ld-linux-x86-64.so.2symlink and instead depend onlibc6-compat's version of that symlink.This broke us, as
/lib/ld-linux-x86-64.so.2was going for glibc, while/lib64/ld-linux-x86-64.so.2was going for musl, and that managed to confuse our binary.Dropping the symlink was justified by
ERROR: glibc*: Packages must not put anything under /lib64, use /lib instead; butman apkbuildtells us about thelib64value foroptions=:That's exactly the case for us! So say
options="lib64"and add the symlink back. Since this means that we file-conflict withlibc6-compat, explicitly declare that and sayconflicts="libc6-compat".What does
libc6-compatdo, what are the consequences of not being able to install both it andglibcat the same time? It adds glibc binary compatibility to musl, allowing binaries linked against glibc to use Alpine's native musl. So it doesn't really make sense to have bothglibcandlibc6-compatto be installed at once; if you haveglibcinstalled that's a strong indicator that you want glibc-linked binaries to use the actual glibc and not musl. So the aboveconflicts=is probably the right thing. At the same time, the intent oflibc6-compatcan be written as "I'd like to be able to run binaries that are linked against glibc", so also sayprovides="libc6-compat".The commit that added
glibc-bin's dependency onlibc6-compat(3987862) said "This package not being installed is a very common cause of reported user errors." I'm not sure what those reported user errors are; that claim doesn't make much sense to me.I also added a
glibc-utilscounterpart tomusl-utils; it just symlinks programs fromglibc-bin's/usr/glibc-compatin to/usr.I also gave
glibc-bina dependency onperl, asmtraceuses perl in its shebang.I have not actually built or tested this.